Nice catch. I guess this contention on hmac computer becomes more severe with use of ipv6 and higher traffic. Most of the time a client will not probe at all before call and if it does, it fires at udp ipv4 before it does tcp v4, if at all. Even if multiple clients probe simultaneously they are serialized over the udp endpoint recvjobqueue. But with ipv6 udp there are two parallell paths.

When I was doing this I was thinking in add two (or more) queues with their own hmacComputer instance and use round robin too avoid contention. Decided that probably is not worth, as you said, this is something that clients do once in a while, then there will be not much pressure on this endpoint I believe. And everything gets conteined already by endpoint queues, so don't think this will cause much delays (only when process different endpoints in simultaneous), still the client should use the lowest response time after an X number of stun responses, which hopefully is enough to avoid wrong decision due contention